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DETAILED ACTION 

1 . Claims 1 -1 9 are subject to examination. 

Response to Arguments 

2. Applicant's arguments with respect to claims 1-8 have been considered but are 
moot in view of the new ground(s) of rejection. 

3. Claim Rejections - 35 USC §101 
Applicant's Argument: 

"In response to the § 101 rejection of claim 8, Applicant has amended claim 8 to 
recite a "computer program on a signal-bearing medium". Applicant submits that a 
"signal-bearing medium" is recognized as statutory subject matter as is evidenced by a 
search of the USPTO's own database, which includes over 250 issued patents that 
claim a "signal-bearing medium." See, e.g., U.S. Patent No 7,072,824, U.S. Patent No. 
7,027,830 and U.S. Patent No. 6,880,040. Therefore, Applicant requests that the § 101 
rejection of claim 8 be withdrawn." 
Examiner's response: 

Claim Rejections - 35 USC §112 

4. The following is a quotation of the first paragraph of 35 U.S.C. 112: 

The specification shall contain a written description of the invention, and of the 
manner and process of making and using it, in such full, clear, concise, and exact 
terms as to enable any person skilled in the art to which it pertains, or with which 
it is most nearly connected, to make and use the same and shall set forth the 
best mode contemplated by the inventor of carrying out his invention. 

5. Claim 8 is rejected under 35 U.S.C. 112, first paragraph, as failing to comply with 
the written description requirement. The claim(s) contains subject matter which was not 
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described in the specification in such a way as to reasonably convey to one skilled in 

the relevant art that the inventor(s), at the time the application was filed, had possession 

of the claimed invention. Claim recites " on a signal-bearing medium" which Examiner 

was not able to locate in the specification. Please advice. 

Claim Rejections - 35 USC § 101 

6. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, 
manufacture, or composition of matter, or any new and useful improvement 
thereof, may obtain a patent therefor, subject to the conditions and requirements 
of this title. 



7. Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is 
directed to non-statutory subject matter. 

Claim 8 recites " a computer program on a signal-bearing medium , the program 
comprising a set of instructions which, when loaded into a processor or a computer, can 
be reasonably interpreted by one of ordinary skill in the art as software, per se, and 
therefore not tangibly embodied in a manner so as to be executable. 

Claim Rejections - 35 USC § 102 

8. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless- 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United 
States only if the international application designated the United States and was published under 
Article 21(2) of such treaty in the English language. 
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9. Claims 1-19 are rejected under 35 U.S.C. 102(e) as being anticipated by Klemets 
et al. (hereinafter Klemets) (US 20030236912 A1) 
Referring to claim 1, 

Klemets teaches a method of streaming multimedia data from a server to a client 
over a network (Fig.1) having a variable bandwidth (para. [0044], "The client 106 may 
send an RTSP request to dynamically measure the connection bandwidth to the server 
104."," The client 106 examines the streaming media format file header to decide which 
streams it wants to select. Several factors influence the client's selection of the streams 
including, but not limited to, the connection bandwidth and the user's language."), the 
multimedia data represented by a set of streams having various predetermined bit rates 
(para. [0032], "For example, there may be multiple available video streams encoded at 
different bit rates (i.e., with different quality) and the client 106 may choose which one to 
receive."), with a subset of streams of the set of streams having bit rates compatible 
with a measured bandwidth of the network (para. [0044], "The client 106 may send an 
RTSP request to dynamically measure the connection bandwidth to the server 104."," 
The client 106 examines the streaming media format file header to decide which 
streams it wants to select. Several factors influence the client's selection of the streams 
including, but not limited to, the connection bandwidth and the user's language."), the 
method being further characterized in that it comprises the steps of 

responsive to descriptions of each stream of the set of streams, configuring the 
client so that the client can decode all the streams within the set of streams (para. 
[0031], "At 110, the client 106 sends an RTSP DESCRIBE request to the media server 



Application/Control Number: 10/525,471 Page 5 

Art Unit: 2154 

104. At 112, the server 104 responds to the RTSP DESCRIBE request with an SDP 
message. The SDP message includes the streaming media format file header and the 
content description list. Clients usually retrieve at least one RTSP uniform resource 
locator (URL) for streaming content from an SDP record retrieved from the server 104 
by means of a DESCRIBE request."), playing all the streams within the set of streams 
(Fig. 4, para. [0041] Referring next to FIG. 3, an exemplary flow diagram illustrates the 
interaction between the client 106 and the server 104 to initiate a streaming media 
session. In the exemplary embodiment of FIG. 3, the server 104 implements RTSP. 
RTSP allows the client 106 to request the delivery of a subset of the streams in the file. 
The client 106 sends a description request (e.g., an RTSP DESCRIBE request) to the 
server 104 to describe the available content. When the server 104 receives a RTSP 
DESCRIBE request, the server 104 responds by encapsulating the streaming media 
format header within a description message (e.g., an SDP message) and transmitting 
the description message via a description protocol (e.g., SDP) to the client 106. In 
RTSP (as defined in RFC 2326), the description message is referred to as a 
presentation description. The header is inserted in the description message in such a 
way that it is ignored by clients that do not have logic to understand the header (see 
FIG. 4). Other information such as the content description list is also included in the 
session description message (see FIG. 4). The SDP message lists each stream that is 
contained in the streaming media format file. SDP establishes a separate URL for each 
stream. In one embodiment, the stream URL is considered to be a stream identifier. In 
other embodiments, the stream identifier is an integer. The stream URL can be used by 
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the client 106 to request delivery of the stream via a playback request (e.g., using the 
RTSP "SETUP" request). For each such URL, the SDP message also specifies the 
corresponding streaming media format stream identifier. This establishes a one-to-one 
mapping between the stream URL and the stream identifier.), muting all the streams 
within the set of streams, except the subset of streams, and decoding the subset of 
streams by the client (para. [0045] In the streaming media format file header, each 
stream is represented by its stream identifier. Hence, the result of the selection process 
is a list of stream identifiers for the streams that were chosen. The description message 
provides a mapping from each stream identifier to a URL. Using this mapping, the client 
106 sends a playback request (e.g., an RTSP SETUP request) for each stream that the 
client 106 has chosen. The client 106 also selects a content description from the 
content description list that relate to the selected media streams. For example, the 
client 106 may select a content description that most closely matches a user's language 
preference to display certain metadata items from that list in a user interface for the 
user. Alternatively or in addition, the client 106 specifies a desired language in an 
Accept-Language header that the client 106 includes in the DESCRIBE request. The 
server 104 selects the content description that most closely matches the requested 
language, and includes the chosen content description in the SDP message sent to the 
client 106. The client 106 may issue a separate RTSP PLAY request for each stream 
that has been chosen to initiate delivery of the chosen streams. Alternatively, the play 
request is included with the playback request with the selected stream identifiers. That 
is, the client 106 may send a separate PLAY command for each stream that has been 
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selected, if the server 104 supports this type of PLAY command. Alternatively, the 
client 106 may send a PLAY request using the URL that controls the presentation as a 
whole. This starts playback of all the selected streams. In response to the playback 
request, the client 106 receives the selected streams (e.g., via RTP) from the server 
104 and renders or otherwise processes the received streams in the Ul for the user. 
For example, the client player Ul may render video, audio, text, and/or animations.") 
Referring to claim 2, 

Klemets teaches the method of streaming multimedia data according to claim 1, 
wherein the step of muting all the streams except the subset of streams is performed by 
the server on a request from the client in accordance with the MUTE/UN MUTE 
extension of the Real Time Streaming Protocol (para. [0045] In the streaming media 
format file header, each stream is represented by its stream identifier. Hence, the result 
of the selection process is a list of stream identifiers for the streams that were chosen. 
The description message provides a mapping from each stream identifier to a URL. 
Using this mapping, the client 106 sends a playback request (e.g., an RTSP SETUP 
request) for each stream that the client 106 has chosen. The client 106 also selects a 
content description from the content description list that relate to the selected media 
streams. For example, the client 106 may select a content description that most closely 
matches a user's language preference to display certain metadata items from that list in 
a user interface for the user. Alternatively or in addition, the client 106 specifies a 
desired language in an Accept-Language header that the client 106 includes in the 
DESCRIBE request. The server 104 selects the content description that most closely 
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matches the requested language, and includes the chosen content description in the 
SDP message sent to the client 106. The client 106 may issue a separate RTSP PLAY 
request for each stream that has been chosen to initiate delivery of the chosen streams. 
Alternatively, the play request is included with the playback request with the selected 
stream identifiers. That is, the client 106 may send a separate PLAY command for each 
stream that has been selected, if the server 104 supports this type of PLAY command. 
Alternatively, the client 106 may send a PLAY request using the URL that controls the 
presentation as a whole. This starts playback of all the selected streams. In response 
to the playback request, the client 106 receives the selected streams (e.g., via RTP) 
from the server 104 and renders or otherwise processes the received streams in the Ul 
for the user. For example, the client player Ul may render video, audio, text, and/or 
animations." Note: Selection inherently performs "MUTE/UNMUTE.") 
Referring to claim 3, 

Klemets teaches a server for serving a client with a subset of streams over a 
network having a variable bandwidth (Fig.1, para. [0044], "The client 106 may send an 
RTSP request to dynamically measure the connection bandwidth to the server 104."," 
The client 106 examines the streaming media format file header to decide which 
streams it wants to select. Several factors influence the client's selection of the streams 
including, but not limited to, the connection bandwidth and the user's language."), said 
server comprising means for selecting the subset of streams within a set of streams 
having various predetermined bit rates (para. [0032], "For example, there may be 
multiple available video streams encoded at different bit rates (i.e., with different quality) 
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and the client 106 may choose which one to receive."), means for playing all the 
streams within the set of streams and means for muting all the streams within the set of 
streams (Fig. 4, para. [0041] Referring next to FIG. 3, an exemplary flow diagram 
illustrates the interaction between the client 106 and the server 104 to initiate a 
streaming media session. In the exemplary embodiment of FIG. 3, the server 104 
implements RTSP. RTSP allows the client 1 06 to request the delivery of a subset of the 
streams in the file. The client 106 sends a description request (e.g., an RTSP 
DESCRIBE request) to the server 104 to describe the available content. When the 
server 104 receives a RTSP DESCRIBE request, the server 104 responds by 
encapsulating the streaming media format header within a description message (e.g., 
an SDP message) and transmitting the description message via a description protocol 
(e.g., SDP) to the client 106. In RTSP (as defined in RFC 2326), the description 
message is referred to as a presentation description. The header is inserted in the 
description message in such a way that it is ignored by clients that do not have logic to 
understand the header (see FIG. 4). Other information such as the content description 
list is also included in the session description message (see FIG. 4). The SDP 
message lists each stream that is contained in the streaming media format file. SDP 
establishes a separate URL for each stream. In one embodiment, the stream URL is 
considered to be a stream identifier. In other embodiments, the stream identifier is an 
integer. The stream URL can be used by the client 106 to request delivery of the 
stream via a playback request (e.g., using the RTSP "SETUP" request). For each such 
URL, the SDP message also specifies the corresponding streaming media format 
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stream identifier. This establishes a one-to-one mapping between the stream URL and 
the stream identifier.), except the subset of streams wherein the server selects the 
subset of streams that have bit rates compatible with a measured bandwidth of the 
network (para. [0044], "The client 106 may send an RTSP request to dynamically 
measure the connection bandwidth to the server 104."," The client 106 examines the 
streaming media format file header to decide which streams it wants to select. Several 
factors influence the client's selection of the streams including, but not limited to, the 
connection bandwidth and the user's language."), and wherein the server provides 
descriptions of all the streams of the set of streams to the client to configure the client 
so that the client can decode all the streams within the set of streams (para. [0045] In 
the streaming media format file header, each stream is represented by its stream 
identifier. Hence, the result of the selection process is a list of stream identifiers for the 
streams that were chosen. The description message provides a mapping from each 
stream identifier to a URL. Using this mapping, the client 106 sends a playback request 
(e.g., an RTSP SETUP request) for each stream that the client 106 has chosen. The 
client 106 also selects a content description from the content description list that relate 
to the selected media streams. For example, the client 106 may select a content 
description that most closely matches a user's language preference to display certain 
metadata items from that list in a user interface for the user. Alternatively or in addition, 
the client 106 specifies a desired language in an Accept-Language header that the 
client 106 includes in the DESCRIBE request. The server 104 selects the content 
description that most closely matches the requested language, and includes the chosen 
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content description in the SDP message sent to the client 106. The client 106 may 
issue a separate RTSP PLAY request for each stream that has been chosen to initiate 
delivery of the chosen streams. Alternatively, the play request is included with the 
playback request with the selected stream identifiers. That is, the client 106 may send a 
separate PLAY command for each stream that has been selected, if the server 104 
supports this type of PLAY command. Alternatively, the client 106 may send a PLAY 
request using the URL that controls the presentation as a whole. This starts playback of 
all the selected streams. In response to the playback request, the client 106 receives 
the selected streams (e.g., via RTP) from the server 104 and renders or otherwise 
processes the received streams in the Ul for the user. For example, the client player Ul 
may render video, audio, text, and/or animations.") 
Referring to claim 4, 

Klemets teaches a server as claimed in claim 3, wherein the means for selecting 
the subset of streams comprise means for measuring the network bandwidth (Fig.1, 
para. [0044], "The client 106 may send an RTSP request to dynamically measure the 
connection bandwidth to the server 104."," The client 106 examines the streaming 
media format file header to decide which streams it wants to select. Several factors 
influence the client's selection of the streams including, but not limited to, the connection 
bandwidth and the user's language.") 
Referring to claim 5, 

Klemets teaches a server as claimed in claim 3, wherein the means for selecting 
the subset of streams are controlled by a request from the client that identifies the 
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subset of streams, the request from the client being in accordance with the 
MUTE/UNMUTE extension of the Real Time Streaming Protocol (para. [0045] In the 
streaming media format file header, each stream is represented by its stream identifier. 
Hence, the result of the selection process is a list of stream identifiers for the streams 
that were chosen. The description message provides a mapping from each stream 
identifier to a URL. Using this mapping, the client 106 sends a playback request (e.g., 
an RTSP SETUP request) for each stream that the client 106 has chosen. The client 
106 also selects a content description from the content description list that relate to the 
selected media streams. For example, the client 106 may select a content description 
that most closely matches a user's language preference to display certain metadata 
items from that list in a user interface for the user. Alternatively or in addition, the client 
106 specifies a desired language in an Accept-Language header that the client 106 
includes in the DESCRIBE request. The server 104 selects the content description that 
most closely matches the requested language, and includes the chosen content 
description in the SDP message sent to the client 106. The client 106 may issue a 
separate RTSP PLAY request for each stream that has been chosen to initiate delivery 
of the chosen streams. Alternatively, the play request is included with the playback 
request with the selected stream identifiers. That is, the client 106 may send a separate 
PLAY command for each stream that has been selected, if the server 104 supports this 
type of PLAY command. Alternatively, the client 106 may send a PLAY request using 
the URL that controls the presentation as a whole. This starts playback of all the 
selected streams. In response to the playback request, the client 106 receives the 
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selected streams (e.g., via RTP) from the server 104 and renders or otherwise 
processes the received streams in the Ul for the user. For example, the client player Ul 
may render video, audio, text, and/or animations." Note: Selection inherently performs 
"MUTE/UNMUTE."). 
Referring to claim 6, 

Klemets teaches a client that decodes a subset of streams within a set of 
streams having various predetermined bit rates, said streams being sent over a network 
having a variable bandwidth, said client comprising means a controller to configure the 
client in order to be able to decode all the streams within the set of streams, select the 
subset of streams having bit rates compatible with the network a measured bandwidth 
of the network, and generate a request to mute all the streams within the set of streams, 
except the subset of streams, the request configured to be transmitted to a server over 
the network (para. [0045] In the streaming media format file header, each stream is 
represented by its stream identifier. Hence, the result of the selection process is a list of 
stream identifiers for the streams that were chosen. The description message provides 
a mapping from each stream identifier to a URL. Using this mapping, the client 106 
sends a playback request (e.g., an RTSP SETUP request) for each stream that the 
client 106 has chosen. The client 106 also selects a content description from the 
content description list that relate to the selected media streams. For example, the 
client 106 may select a content description that most closely matches a user's language 
preference to display certain metadata items from that list in a user interface for the 
user. Alternatively or in addition, the client 106 specifies a desired language in an 



Application/Control Number: 10/525,471 Page 14 

Art Unit: 2154 

Accept-Language header that the client 106 includes in the DESCRIBE request. The 
server 104 selects the content description that most closely matches the requested 
language, and includes the chosen content description in the SDP message sent to the 
client 106. The client 106 may issue a separate RTSP PLAY request for each stream 
that has been chosen to initiate delivery of the chosen streams. Alternatively, the play 
request is included with the playback request with the selected stream identifiers. That 
is, the client 106 may send a separate PLAY command for each stream that has been 
selected, if the server 104 supports this type of PLAY command. Alternatively, the 
client 106 may send a PLAY request using the URL that controls the presentation as a 
whole. This starts playback of all the selected streams. In response to the playback 
request, the client 106 receives the selected streams (e.g., via RTP) from the server 
104 and renders or otherwise processes the received streams in the Ul for the user. 
For example, the client player Ul may render video, audio, text, and/or animations." 
Note: Selection inherently performs "MUTE/UNMUTE.") 
Referring to claim 7, 

Klemets teaches a telecommunication system (Fig.1) comprising a server for 
serving a client (Fig.1) with a subset of streams, said server comprising means for 
selecting the subset of streams within a set of streams having various predetermined bit 
rates, means for playing all the streams within the set of streams and means for muting 
streams (Fig. 4, para. [0041] Referring next to FIG. 3, an exemplary flow diagram 
illustrates the interaction between the client 106 and the server 104 to initiate a 
streaming media session. In the exemplary embodiment of FIG. 3, the server 104 
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implements RTSP. RTSP allows the client 1 06 to request the delivery of a subset of the 
streams in the file. The client 106 sends a description request (e.g., an RTSP 
DESCRIBE request) to the server 104 to describe the available content. When the 
server 104 receives a RTSP DESCRIBE request, the server 104 responds by 
encapsulating the streaming media format header within a description message (e.g., 
an SDP message) and transmitting the description message via a description protocol 
(e.g., SDP) to the client 106. In RTSP (as defined in RFC 2326), the description 
message is referred to as a presentation description. The header is inserted in the 
description message in such a way that it is ignored by clients that do not have logic to 
understand the header (see FIG. 4). Other information such as the content description 
list is also included in the session description message (see FIG. 4). The SDP 
message lists each stream that is contained in the streaming media format file. SDP 
establishes a separate URL for each stream. In one embodiment, the stream URL is 
considered to be a stream identifier. In other embodiments, the stream identifier is an 
integer. The stream URL can be used by the client 106 to request delivery of the 
stream via a playback request (e.g., using the RTSP "SETUP" request). For each such 
URL, the SDP message also specifies the corresponding streaming media format 
stream identifier. This establishes a one-to-one mapping between the stream URL and 
the stream identifier." para. [0045] In the streaming media format file header, each 
stream is represented by its stream identifier. Hence, the result of the selection process 
is a list of stream identifiers for the streams that were chosen. The description message 
provides a mapping from each stream identifier to a URL. Using this mapping, the client 
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106 sends a playback request (e.g., an RTSP SETUP request) for each stream that the 
client 106 has chosen. The client 106 also selects a content description from the 
content description list that relate to the selected media streams. For example, the 
client 106 may select a content description that most closely matches a user's language 
preference to display certain metadata items from that list in a user interface for the 
user. Alternatively or in addition, the client 106 specifies a desired language in an 
Accept-Language header that the client 106 includes in the DESCRIBE request. The 
server 104 selects the content description that most closely matches the requested 
language, and includes the chosen content description in the SDP message sent to the 
client 106. The client 106 may issue a separate RTSP PLAY request for each stream 
that has been chosen to initiate delivery of the chosen streams. Alternatively, the play 
request is included with the playback request with the selected stream identifiers. That 
is, the client 106 may send a separate PLAY command for each stream that has been 
selected, if the server 104 supports this type of PLAY command. Alternatively, the 
client 106 may send a PLAY request using the URL that controls the presentation as a 
whole. This starts playback of all the selected streams. In response to the playback 
request, the client 106 receives the selected streams (e.g., via RTP) from the server 
104 and renders or otherwise processes the received streams in the Ul for the user. 
For example, the client player Ul may render video, audio, text, and/or animations."), a 
network having a variable bandwidth (para. [0044], "The client 106 may send an RTSP 
request to dynamically measure the connection bandwidth to the server 104."," The 
client 106 examines the streaming media format file header to decide which streams it 
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wants to select. Several factors influence the client's selection of the streams including, 
but not limited to, the connection bandwidth and the user's language. ")and a client 
decodes the subset of streams, said client comprising configuring means for configuring 
the client to be able to decode all the streams within the set of streams (para. [0031], "At 
110, the client 106 sends an RTSP DESCRIBE request to the media server 104. At 
112, the server 104 responds to the RTSP DESCRIBE request with an SDP message. 
The SDP message includes the streaming media format file header and the content 
description list. Clients usually retrieve at least one RTSP uniform resource locator 
(URL) for streaming content from an SDP record retrieved from the server 104 by 
means of a DESCRIBE request."), means for selecting a the subset of streams having 
bit rates compatible with a measured bandwidth of the network and means for 
requesting that the server mute all the streams within the set of streams, except the 
subset of streams (para. [0045] In the streaming media format file header, each stream 
is represented by its stream identifier. Hence, the result of the selection process is a list 
of stream identifiers for the streams that were chosen. The description message 
provides a mapping from each stream identifier to a URL. Using this mapping, the client 
106 sends a playback request (e.g., an RTSP SETUP request) for each stream that the 
client 106 has chosen. The client 106 also selects a content description from the 
content description list that relate to the selected media streams. For example, the 
client 106 may select a content description that most closely matches a user's language 
preference to display certain metadata items from that list in a user interface for the 
user. Alternatively or in addition, the client 106 specifies a desired language in an 
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Accept-Language header that the client 106 includes in the DESCRIBE request. The 
server 104 selects the content description that most closely matches the requested 
language, and includes the chosen content description in the SDP message sent to the 
client 106. The client 106 may issue a separate RTSP PLAY request for each stream 
that has been chosen to initiate delivery of the chosen streams. Alternatively, the play 
request is included with the playback request with the selected stream identifiers. That 
is, the client 106 may send a separate PLAY command for each stream that has been 
selected, if the server 104 supports this type of PLAY command. Alternatively, the 
client 106 may send a PLAY request using the URL that controls the presentation as a 
whole. This starts playback of all the selected streams. In response to the playback 
request, the client 106 receives the selected streams (e.g., via RTP) from the server 
104 and renders or otherwise processes the received streams in the Ul for the user. 
For example, the client player Ul may render video, audio, text, and/or animations.") 
Referring to claim 8, 

Claim 8 is a claim to a computer program comprising a set of instructions which, 
when loaded into a processor or a computer, causes the processor or the computer to 
carry out the method as claimed in Claim 1. Therefore claim 8 is rejected for the 
reasons set forth for claim 1 . 
Referring to claim 9, 

Klemets teaches a method of streaming multimedia data according to claim 1, 
wherein the step of configuring the client so that the client can decode all the streams 
within the set of streams includes the server sending the descriptions of the set of 
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streams to the client responsive to a request from the client to the server in accordance 
with the DESCRIBE command of the Real Time Streaming Protocol (Fig. 4, para. [0041] 
Referring next to FIG. 3, an exemplary flow diagram illustrates the interaction between 
the client 106 and the server 104 to initiate a streaming media session. In the 
exemplary embodiment of FIG. 3, the server 104 implements RTSP. RTSP allows the 
client 106 to request the delivery of a subset of the streams in the file. The client 106 
sends a description request (e.g., an RTSP DESCRIBE request) to the server 104 to 
describe the available content. When the server 104 receives a RTSP DESCRIBE 
request, the server 104 responds by encapsulating the streaming media format header 
within a description message (e.g., an SDP message) and transmitting the description 
message via a description protocol (e.g., SDP) to the client 106. In RTSP (as defined in 
RFC 2326), the description message is referred to as a presentation description. The 
header is inserted in the description message in such a way that it is ignored by clients 
that do not have logic to understand the header (see FIG. 4). Other information such as 
the content description list is also included in the session description message (see FIG. 
4). The SDP message lists each stream that is contained in the streaming media format 
file. SDP establishes a separate URL for each stream. In one embodiment, the stream 
URL is considered to be a stream identifier. In other embodiments, the stream identifier 
is an integer. The stream URL can be used by the client 106 to request delivery of the 
stream via a playback request (e.g., using the RTSP "SETUP" request). For each such 
URL, the SDP message also specifies the corresponding streaming media format 
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stream identifier. This establishes a one-to-one mapping between the stream URL and 
the stream identifier."). 
Referring to claim 10, 

Klemets teaches a method of streaming multimedia data according to claim 1, 
wherein the client includes a plurality of decoders each of which is configured to decode 
one of the streams of the set of streams (Para. [0133], "asf file. Para. [0010], The 
header object of an ASF file stores information as metadata that is needed by a client to 
decode and render the captured data."). 
Referring to claim 11, 

Klemets teaches a method of streaming multimedia data according to claim 1, 
further comprising, responsive to a change in the measured bandwidth of the network, 
selecting a second subset of streams of the set of streams that have rates compatible 
with the measured bandwidth of the network, muting all the streams within the set of 
streams except the second subset of streams, and decoding the second subset of 
streams by the client, wherein switching from decoding the subset of streams to 
decoding the second subset of steams does not require reconfiguration of the client 
(para. [0044], "The client 106 may send an RTSP request to dynamically measure the 
connection bandwidth to the server 104."," The client 106 examines the streaming 
media format file header to decide which streams it wants to select. Several factors 
influence the client's selection of the streams including, but not limited to, the connection 
bandwidth and the user's language."). 
Referring to claim 12, 
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Klemets teaches a method of streaming multimedia data according to claim 1, 
wherein the client measures the bandwidth of the network, selects the subset of 
streams compatible with the measured bandwidth, and requests that the server mute all 
the streams of the set of streams except the subset of streams, the request from the 
client to the server being in accordance with the MUTE/UN MUTE extension of the Real 
Time Streaming Protocol (para. [0044], "The client 106 may send an RTSP request to 
dynamically measure the connection bandwidth to the server 104."," The client 106 
examines the streaming media format file header to decide which streams it wants to 
select. Several factors influence the client's selection of the streams including, but not 
limited to, the connection bandwidth and the user's language." para. [0045] In the 
streaming media format file header, each stream is represented by its stream identifier. 
Hence, the result of the selection process is a list of stream identifiers for the streams 
that were chosen. The description message provides a mapping from each stream 
identifier to a URL. Using this mapping, the client 106 sends a playback request (e.g., 
an RTSP SETUP request) for each stream that the client 106 has chosen. The client 
106 also selects a content description from the content description list that relate to the 
selected media streams. For example, the client 106 may select a content description 
that most closely matches a user's language preference to display certain metadata 
items from that list in a user interface for the user. Alternatively or in addition, the client 
106 specifies a desired language in an Accept-Language header that the client 106 
includes in the DESCRIBE request. The server 104 selects the content description that 
most closely matches the requested language, and includes the chosen content 
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description in the SDP message sent to the client 106. The client 106 may issue a 
separate RTSP PLAY request for each stream that has been chosen to initiate delivery 
of the chosen streams. Alternatively, the play request is included with the playback 
request with the selected stream identifiers. That is, the client 106 may send a separate 
PLAY command for each stream that has been selected, if the server 104 supports this 
type of PLAY command. Alternatively, the client 106 may send a PLAY request using 
the URL that controls the presentation as a whole. This starts playback of all the 
selected streams. In response to the playback request, the client 106 receives the 
selected streams (e.g., via RTP) from the server 104 and renders or otherwise 
processes the received streams in the Ul for the user. For example, the client player Ul 
may render video, audio, text, and/or animations." Note: Selection inherently performs 
"MUTE/UNMUTE."). 
Referring to claim 13, 

Klemets teaches a server as claimed in claim 3, wherein the server provides the 
descriptions of all the streams of the set of streams to the client responsive to a request 
from the client in accordance with the DESCRIBE command of the Real Time 
Streaming Protocol (Fig. 4, para. [0041] Referring next to FIG. 3, an exemplary flow 
diagram illustrates the interaction between the client 106 and the server 104 to initiate a 
streaming media session. In the exemplary embodiment of FIG. 3, the server 104 
implements RTSP. RTSP allows the client 1 06 to request the delivery of a subset of the 
streams in the file. The client 106 sends a description request (e.g., an RTSP 
DESCRIBE request) to the server 104 to describe the available content. When the 
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server 104 receives a RTSP DESCRIBE request, the server 104 responds by 
encapsulating the streaming media format header within a description message (e.g., 
an SDP message) and transmitting the description message via a description protocol 
(e.g., SDP) to the client 106. In RTSP (as defined in RFC 2326), the description 
message is referred to as a presentation description. The header is inserted in the 
description message in such a way that it is ignored by clients that do not have logic to 
understand the header (see FIG. 4). Other information such as the content description 
list is also included in the session description message (see FIG. 4). The SDP 
message lists each stream that is contained in the streaming media format file. SDP 
establishes a separate URL for each stream. In one embodiment, the stream URL is 
considered to be a stream identifier. In other embodiments, the stream identifier is an 
integer. The stream URL can be used by the client 106 to request delivery of the 
stream via a playback request (e.g., using the RTSP "SETUP" request). For each such 
URL, the SDP message also specifies the corresponding streaming media format 
stream identifier. This establishes a one-to-one mapping between the stream URL and 
the stream identifier."). 
Referring to claim 14, 

Klemets teaches a client as claimed in claim 6, further comprising a plurality of 
decoders each of which is configured by the means for configuring to decode one of the 
streams of the set of streams (Para. [0133], "asf file. Para. [0010], The header object 
of an ASF file stores information as metadata that is needed by a client to decode and 
render the captured data.") 
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Referring to claim 15, 

Klemets teaches a client as claimed in claim 14, wherein the plurality of decoders 
are configured responsive to descriptions of all the streams of the set of streams being 
provided to the client by a server, the descriptions being provided in response to a 
request by the client in accordance with the DESCRIBE command of the Real Time 
Streaming Protocol (Fig. 4, para. [0041] Referring next to FIG. 3, an exemplary flow 
diagram illustrates the interaction between the client 106 and the server 104 to initiate a 
streaming media session. In the exemplary embodiment of FIG. 3, the server 104 
implements RTSP. RTSP allows the client 1 06 to request the delivery of a subset of the 
streams in the file. The client 106 sends a description request (e.g., an RTSP 
DESCRIBE request) to the server 104 to describe the available content. When the 
server 104 receives a RTSP DESCRIBE request, the server 104 responds by 
encapsulating the streaming media format header within a description message (e.g., 
an SDP message) and transmitting the description message via a description protocol 
(e.g., SDP) to the client 106. In RTSP (as defined in RFC 2326), the description 
message is referred to as a presentation description. The header is inserted in the 
description message in such a way that it is ignored by clients that do not have logic to 
understand the header (see FIG. 4). Other information such as the content description 
list is also included in the session description message (see FIG. 4). The SDP 
message lists each stream that is contained in the streaming media format file. SDP 
establishes a separate URL for each stream. In one embodiment, the stream URL is 
considered to be a stream identifier. In other embodiments, the stream identifier is an 
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integer. The stream URL can be used by the client 106 to request delivery of the 
stream via a playback request (e.g., using the RTSP "SETUP" request). For each such 
URL, the SDP message also specifies the corresponding streaming media format 
stream identifier. This establishes a one-to-one mapping between the stream URL and 
the stream identifier.") 
Referring to claim 16, 

Klemets teaches a telecommunication system as claimed in claim 7, wherein the 
client sends a request in accordance with the MUTE/UN MUTE extension of the Real 
Time Streaming Protocol to the server to request that the server mute all the streams 
within the set of streams except the subset of streams (para. [0044], "The client 106 may 
send an RTSP request to dynamically measure the connection bandwidth to the server 
104."," The client 106 examines the streaming media format file header to decide which 
streams it wants to select. Several factors influence the client's selection of the streams 
including, but not limited to, the connection bandwidth and the user's language." para. 
[0045] In the streaming media format file header, each stream is represented by its 
stream identifier. Hence, the result of the selection process is a list of stream identifiers 
for the streams that were chosen. The description message provides a mapping from 
each stream identifier to a URL. Using this mapping, the client 106 sends a playback 
request (e.g., an RTSP SETUP request) for each stream that the client 106 has chosen. 
The client 106 also selects a content description from the content description list that 
relate to the selected media streams. For example, the client 106 may select a content 
description that most closely matches a user's language preference to display certain 
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metadata items from that list in a user interface for the user. Alternatively or in addition, 
the client 106 specifies a desired language in an Accept-Language header that the 
client 106 includes in the DESCRIBE request. The server 104 selects the content 
description that most closely matches the requested language, and includes the chosen 
content description in the SDP message sent to the client 106. The client 106 may 
issue a separate RTSP PLAY request for each stream that has been chosen to initiate 
delivery of the chosen streams. Alternatively, the play request is included with the 
playback request with the selected stream identifiers. That is, the client 106 may send a 
separate PLAY command for each stream that has been selected, if the server 104 
supports this type of PLAY command. Alternatively, the client 106 may send a PLAY 
request using the URL that controls the presentation as a whole. This starts playback of 
all the selected streams. In response to the playback request, the client 106 receives 
the selected streams (e.g., via RTP) from the server 104 and renders or otherwise 
processes the received streams in the Ul for the user. For example, the client player Ul 
may render video, audio, text, and/or animations." Note: Selection inherently performs 
"MUTE/UNMUTE.") 
Referring to claim 17, 

Klemets teaches a telecommunication system as claimed in claim 7, wherein the 
client further includes a plurality of decoders each of which is configured by the means 
for configuring to decode one of the streams of the set of streams (Para. [0133], "asf 
file. Para. [0010], The header object of an ASF file stores information as metadata that 
is needed by a client to decode and render the captured data.") 
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Referring to claim 18, 

Klemets teaches a telecommunication system as claimed in claim 17, wherein 
the plurality of decoders are configured responsive to descriptions of all the streams of 
the set of streams being provided to the client by the server, the descriptions being 
provided in response to a request by the client in accordance with the DESCRIBE 
command of the Real Time Streaming Protocol para. [0045] In the streaming media 
format file header, each stream is represented by its stream identifier. Hence, the result 
of the selection process is a list of stream identifiers for the streams that were chosen. 
The description message provides a mapping from each stream identifier to a URL. 
Using this mapping, the client 106 sends a playback request (e.g., an RTSP SETUP 
request) for each stream that the client 106 has chosen. The client 106 also selects a 
content description from the content description list that relate to the selected media 
streams. For example, the client 106 may select a content description that most closely 
matches a user's language preference to display certain metadata items from that list in 
a user interface for the user. Alternatively or in addition, the client 106 specifies a 
desired language in an Accept-Language header that the client 106 includes in the 
DESCRIBE request. The server 104 selects the content description that most closely 
matches the requested language, and includes the chosen content description in the 
SDP message sent to the client 106. The client 106 may issue a separate RTSP PLAY 
request for each stream that has been chosen to initiate delivery of the chosen streams. 
Alternatively, the play request is included with the playback request with the selected 
stream identifiers. That is, the client 106 may send a separate PLAY command for each 
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stream that has been selected, if the server 104 supports this type of PLAY command. 
Alternatively, the client 106 may send a PLAY request using the URL that controls the 
presentation as a whole. This starts playback of all the selected streams. In response 
to the playback request, the client 106 receives the selected streams (e.g., via RTP) 
from the server 104 and renders or otherwise processes the received streams in the Ul 
for the user. For example, the client player Ul may render video, audio, text, and/or 
animations.") 
Referring to claim 19, 

Klemets teaches a telecommunication system as claimed in claim 7, wherein the client 
measures the bandwidth of the network, selects the subset of streams compatible with 
the measured bandwidth, and requests that the server mute all the streams of the set of 
streams except the subset of streams, the request from the client to the server being in 
accordance with the MUTE/UN MUTE extension of the Real Time Streaming Protocol 
(para. [0044], "The client 106 may send an RTSP request to dynamically measure the 
connection bandwidth to the server 104."," The client 106 examines the streaming 
media format file header to decide which streams it wants to select. Several factors 
influence the client's selection of the streams including, but not limited to, the connection 
bandwidth and the user's language." para. [0045] In the streaming media format file 
header, each stream is represented by its stream identifier. Hence, the result of the 
selection process is a list of stream identifiers for the streams that were chosen. The 
description message provides a mapping from each stream identifier to a URL. Using 
this mapping, the client 106 sends a playback request (e.g., an RTSP SETUP request) 
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for each stream that the client 106 has chosen. The client 106 also selects a content 
description from the content description list that relate to the selected media streams. 
For example, the client 106 may select a content description that most closely matches 
a user's language preference to display certain metadata items from that list in a user 
interface for the user. Alternatively or in addition, the client 106 specifies a desired 
language in an Accept-Language header that the client 106 includes in the DESCRIBE 
request. The server 104 selects the content description that most closely matches the 
requested language, and includes the chosen content description in the SDP message 
sent to the client 106. The client 106 may issue a separate RTSP PLAY request for 
each stream that has been chosen to initiate delivery of the chosen streams. 
Alternatively, the play request is included with the playback request with the selected 
stream identifiers. That is, the client 106 may send a separate PLAY command for each 
stream that has been selected, if the server 104 supports this type of PLAY command. 
Alternatively, the client 106 may send a PLAY request using the URL that controls the 
presentation as a whole. This starts playback of all the selected streams. In response 
to the playback request, the client 106 receives the selected streams (e.g., via RTP) 
from the server 104 and renders or otherwise processes the received streams in the Ul 
for the user. For example, the client player Ul may render video, audio, text, and/or 
animations." Note: Selection inherently performs "MUTE/UNMUTE.") 
Conclusion 

Examiner's note: Examiner has cited particular columns and line numbers in the 
references as applied to the claims above for the convenience of the applicant. 
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Although the specified citations are representative of the teachings of the art and are 
applied to the specific limitations within the individual claim, other passages and figures 
may apply as well. It is respectfully requested from the applicant in preparing responses, 
to fully consider the references in entirety as potentially teaching all or part of the 
claimed invention, as well as the context of the passage as taught by the prior art or 
disclosed by the Examiner. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Ashok B. Patel whose telephone number is (571) 272- 
3972. The examiner can normally be reached on 6:30 am-4:30 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Nathan A. Flynn can be reached on (571) 272-1915. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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